Content-aware digital media storage device and methods of using the same

ABSTRACT

A content-aware digital media storage device includes a host device interface for exchanging digital information with a host device, a memory array for storing digital information received from the host device via the host interface, a peripheral module configured to communicate the digital information stored in the memory array to a receiver located remote from the digital media storage device, and a controller communicatively coupled to the host device interface, the memory array and the peripheral module and configured to interpret directory information associated with the digital information stored in the memory array so as to selectively access said digital information and communicate such accessed digital information to the peripheral module for transmission to the remote receiver. Digital images stored in the memory array may be transmitted to a remote host via a wireless network access point with which the peripheral module of the storage device is associated.

RELATED APPLICATIONS

This application is a CONTINUATION of U.S. patent application Ser. No.12/749,485, filed 29 Mar. 2010, which is a DIVISIONAL of U.S. patentapplication Ser. No. 11/468,251, filed 29 Aug. 2006, now U.S. Pat. No.7,702,821, which claims the priority benefit of U.S. Provisional PatentApplication 60/718,155, filed 15 Sep. 2005, all of which areincorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to storage media for digital media devicessuch as cameras, audio/video recorders/players, and the like, and, moreparticularly, to such storage media as incorporate peripheral devicesfor transferring digital media stored therein via wireless communicationlinks or otherwise processing said media.

BACKGROUND

Devices such as digital still cameras (“DSCs”) rely on removable,non-volatile media cards to store image and other data (e.g., metadataconcerning the image data). Other digital media devices such asaudio/video recorders/players (e.g., mobile phones, personal digitalassistants, MP3 players, digital video cameras, etc.) also use suchmedia cards to store a variety of digital media (e.g., images, movies,audio, etc.). Several media card formats exist, including Secure Digital(SD), Multi Media Card (MMC), Compact Flash (CF) I and II, Memory Stick(MS), and xD Picture Card (xD). As used herein, the term media card isintended to refer to all such digital media storage devices, regardlessof physical format.

Generally, extracting images or other data from these media cardsrequires a tethered connection to a personal computer (or similardevice) or printer. For example, images can be downloaded directly tohard copy using printers that support physical interfaces compatiblewith the media card. Alternatively, images may be uploaded to personalcomputers via card readers or wired connections between the camerashosting the media cards and the computers.

More recently, digital cameras having wireless network connectivity havebecome available. These cameras permit connectivity with wirelessnetworks (usually such networks as are compliant with the IEEE 802.11a/b/g standards) to transfer image data from the media card to apersonal computer or printer. However, such cameras are generally moreexpensive than non-wireless network capable DSCs and, given the presentinstalled base of non-wireless network capable DSCs, represent only avery small portion of the overall number of DSCs available today.

U.S. Pat. No. 6,405,278 to Liepe describes a flash memory cardconfigured with flash memory (e.g., for storing digital images) and anRF transmitter that allows data stored within the flash memory to betransferred via direct wireless communication with an extended storagedevice having a compatible receiver. Liepe does not, however, discussthe issues of metadata associated with any of the data being so storedor transferred, nor does the reference describe any intelligenceresident within the flash card that allows for manipulation of thestorage media that is visible to its host. Further, communicationbetween the memory card and the extended storage device is limited todirect communication without provision for making use of wireless LANsand the like.

Davis, et al. have reported on “the social life of cameraphone images”based on a study of multiple users' experiences with speciallyconfigured mobile phones having integrated digital cameras. See, e.g.,Davis et al., “MMM2: Mobile media Metadata for Media Sharing”, CHI2005,Apr. 2-7, 2005, Portland, Oreg. According to the authors, a significantsource of frustration for users of digital cameras (whether cameraphonesor otherwise) is getting photos off of the host device and onto aplatform where they can be shared with others. The MMM2 applicationallows users of these special camerphones to add captions to picturesand video captured by the host's camera and to share those images andvideos with other MMM2 users via existing networks used by mobilephones. Images stored in the MMM2 database can later be organized intoalbums, etc.

An important limitation of the MMM2 system is that it requires softwareupgrades to the host device. Specifically, before the cameraphones couldbe deployed to the users for participation in the above-described study,they had to be configured with client-side software configured toautomatically gather contextual metadata before the images were uploadedto the MMM2 database. Additional client-side enhancements to thecamerphone's existing XHTML browser were required to permit userinteraction with the images in order to facilitate annotation andsharing thereof.

While such enhancements to the firmware and/or application software of ahost device may be possible or even practical in a controlled andrelatively small environment (such as that used for the above-describedstudy), they are not practical (or even, in some cases, possible) inlarger arenas, such as the existing installed based of legacy DSCs thatare not wireless-network capable. Hence, what is needed is a differentsolution to address the problem of getting the photos (or, moregenerally, other digital media) off the host device, especially wheresuch host does not permit easy modification of its firmware orapplication software.

SUMMARY OF THE INVENTION

In one embodiment, the present invention provides a content-awaredigital media storage device having a host device interface forexchanging digital information with a host device, a memory array forstoring digital information received from the host device via the hostinterface, a peripheral module configured to communicate the digitalinformation stored in the memory array to a receiver located remote fromthe digital media storage device, and a controller communicativelycoupled to the host device interface, the memory array and theperipheral module and configured to interpret directory informationassociated with the digital information stored in the memory array so asto selectively access said digital information and communicate suchaccessed digital information to the peripheral module for transmissionto the remote receiver. The controller is preferably configured tointerpret the directory information under the control of computerreadable instructions, which may be stored in the memory array oranother memory associated with the storage device. Further, thecontroller may be configured to recognize the type and nature of thedigital information stored in the memory array. The peripheral modulemay be a wireless transceiver and the digital media storage devicepreferably has a form factor compatible with at least one of the familyof secure digital media cards, multi media cards, compact flash (CF)media cards, memory sticks, or xD picture cards.

In a further embodiment, the present invention provides for transmittinga digital image stored in the memory storage array of a removable mediacard to a host (e.g., accessible via a local area network (LAN), widearea network (WAN), or network of networks such as the Internet) via awireless radio transceiver included in the media card. Such atransmission is made, in part, through an appropriate wireless networkinfrastructure device (such as wireless network access point associatedwith a network conforming to the IEEE 802.11 standards) with which thewireless radio transceiver of the removable media card is associated.From the host the digital image is transferred to an electronic photoalbum, for example as may be maintained by a third party photo serviceprovider.

Prior to transferring the digital image from the host to the electronicphoto album, the digital image may be associated with metadataconcerning a location at which the digital image was captured by thedigital camera. Metadata may pertain to the identity of the camera user,the identity of other users in the vicinity, a timezone referencedtimestamp, or information concerning a location at which the digitalimage was captured by the digital camera. Such location and timezonemetadata may be derived from global positioning system (GPS) data; frominformation concerning wireless networks determined to be near the mediacard when the image was captured by the digital camera; from informationconcerning wireless networks detected by the media card; or combinationsof any of the foregoing. In addition, the digital image may be processedso as to be compatible with image format requirements for storage in theelectronic photo album.

A further embodiment of the present invention provides for automaticallyassociating a wireless radio transceiver of a removable media cardhaving a memory array storing digital images captured by a digitalcamera with an access point of a wireless network. Such association ismade according to configuration information stored in the memory arrayof the media card. One or more of the digital images are thentransferred from the media card to a computer system, at least in partthrough the wireless network.

The computer system to which the images are transferred may be a serverconfigured to receive those digital images to transfer same to anelectronic photo album, for example an album hosted at a computerresource other than the server. Prior to transferring the digitalimages, however, those images may be associated with metadata concerningapproximate geographic locations at which the images were captured, thetimezone in which the images were captured, and other wireless users inthe vicinity at that time.

Still a further embodiment of the present invention provides fordisplaying to a user one or more images retrieved from a memory array ofa removable media card according to the status of a transfer of at leastone other image from the memory array of the media card to a computersystem via a wireless network with which a wireless radio transceiver ofthe removable media card is communicatively coupled to. The one or moreimages may be displayed via a display device of a digital camera withinwhich the removable media card is hosted. In some cases the one or moreimages may be part of a movie. Regardless, however, the imagespreferably include status information concerning the transfer of the atleast one other image.

Yet a further embodiment of the present invention provides forexchanging information between two removable media cards via an ad hocwireless network established between respective wireless radiotransceivers of those media cards. The information may be indicative ofproximity of the two media cards to one another and may be subsequentlyuploaded from the respective media cards to a computer resource.

Once so uploaded, the information from the media cards may be correlatedalong with profile information concerning users of the two media cardsto determine whether or not the users should be advised of theinformation exchange. For example, the users may be so advised if theprofile information concerning the users indicates they have arelationship to/with one another. Such a relationship may be indicatedthrough social network contacts between the users. In the event theusers are to be advised of the information exchange, the advisory may bemade in a form of a prompt to share digital images with one another.

It is worth noting that some embodiments of the present invention do notrequire the use of wireless network-capable media cards. Instead,wireless network-capable cameras having conventional media cards may beused. For example, the server-layer functions involving the associationof metadata and image data described herein may be performed regardlessof whether it is the media card, the camera (or both) that are wirelessnetwork-capable. Unlike the MMM2 system described above, the presentserver-layer operations avoid the need for specialized firmware to beinstalled on the image capture device.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example, and notlimitation, in the figures of the accompanying drawings, in which:

FIG. 1 illustrates a block diagram of a removable media card having awireless network port in accordance with an embodiment of the presentinvention.

FIG. 2 illustrates a further example of a removable media card having awireless network port in accordance with an embodiment of the presentinvention

FIG. 3 illustrate an example of a wireless network configured for usewith a removable media card having a wireless network port in accordancewith an embodiment of the present invention.

FIGS. 4A and 4B illustrate examples of a user interface for use withimage uploads from a removable media card having a wireless network portin accordance with an embodiment of the present invention.

FIG. 5 illustrates steps for setting up and operating an authenticationmechanism of a media card configured in accordance with embodiments ofthe present invention.

DESCRIPTION

Described herein are content-aware digital media storage devices. Suchdevices may be configured to be compatible with existing specificationsfor media card formats. That is, the present devices may be configuredwith physical dimensions compatible with such specifications. In thisway the present content-aware digital media storage devices can replaceor substitute for conventional media cards in legacy devices such asDSCs and other digital media devices.

In the context of the present invention, the term “content” is meant toimply both the file system type and structure employed by the hostdevice and, at a higher layer, the type and nature of the files utilizedthereby. Hence, the term “content-aware” is meant to reflect the factthat the present digital media storage devices are configured withintelligence capable of recognizing these file system types andstructures and the type and nature of said files. In various embodimentsof the invention such intelligence may be implemented ascomputer-readable instructions to be executed by a general (or special)purpose processing device capable of reading said instructions andacting in accordance therewith (i.e., firmware or, more generally,software) or dedicated hardware configured to perform the functionsdescribed herein (or a combination of hardware and software).

In addition to the above-described intelligence, the present digitalmedia storage devices may be configured with various peripherals (e.g.,in addition to the memory array and memory controller portions of thedevice). For example, uni- or bi-directional radio frequency circuitrymay be included in the device to permit RF communications between thedigital media storage device and a compatibletransmitter/receiver/transceiver. In one embodiment, this RF circuitrycomprises a wireless two-way radio configured for communicationsaccording to the IEEE 802.11 a/b/g standards or other wirelesscommunication protocols, in ad-hoc and/or infrastructure modes.Alternatively, or in addition, the RF circuitry may include a globalpositioning system (GPS) receiver for receiving information from GPS orsimilar satellites or pseudolites or other platforms which transmitsimilar information. Other types of peripherals may also be included.

Other embodiments of the present digital media storage device (with orwithout the peripherals described above) may includesoftware/firmware/hardware for digital media processing. For example,means for image processing, digital rights management, or otheractivities or functions may be included. Hence, the digital mediastorage device may be configured to substantially manipulate the digitalmedia data stored therein prior to transferring the modified (and, insome cases, the original) data off of the storage device (e.g., via RFcommunication).

Digital media storage devices configured in accordance with embodimentsof the present invention include, in addition to a flash memory array, acontroller that communicatively couples a microprocessor or similardevice (e.g., a digital signal processor, reduced instruction setprocessor, etc.) configured to execute computer-readable instructionswith flash memory array-facing and host-facing physical layer interfacelogic. In this context, the “host” being referred to is the device(e.g., the camera, audio player or other host device) which will use thedigital media storage device as a repository for digital data (e.g.,images, audio files, and the like). The microprocessor executes thecomputer-readable instructions (which may be stored in the flash memoryarray, a separate memory device communicatively coupled to themicroprocessor, or both), which proxy all accesses from the host-facingphysical layer interface of the storage device (i.e., the interface withthe DSC or other digital device) to the flash memory array.

Unlike a conventional flash controller, the present microprocessor andassociated firmware make digital media storage devices configured inaccordance with the present invention capable of interpreting andprocessing the data stored in the flash array. The present firmware usesthe file system structure written to the flash array to “mount” thedevice (before a computer can use any kind of storage media theoperating system must make that media accessible through the computer'sfile system—a process known as mounting), obtain an inventory of filesstored thereon, read the contents of those files, and (if desired) makemodifications to the file system. Such modifications include, but arenot limited to, removing and renaming files, updating file attributes,and creating new files. This is in distinct contrast to conventionalflash array controllers, which merely stage the information beingwritten to the storage array in the form of fixed-size blocks of opaquedata and take the appropriate actions to write the blocks to the array.

In one embodiment then, the present digital media storage deviceinterrupts the external host from directly addressing the flash array.Instead, all accesses by the host device are proxied and translated bythe firmware before resolving to a specific block of data in the flasharray. The digital media storage device may be readied for suchactivities by first formatting the device (e.g., in the conventionalfashion), if necessary, and then initializing an internal mapping tableto directly map all the blocks that have been written during the formatoperation and un-mapping all other blocks in the array. As a result,after the operation is completed, only data blocks that contain filesystem metadata such as the File Allocation Table (FAT), Root DirectoryStructure and Partition Boot Record have a valid translation fromlogical block addresses presented at the host interface to physicaladdresses within the digital media storage device. All other blocks areconsidered unused and unallocated and are not directly accessible by thehost device.

From this initialized state, the digital media storage device maintainspersistent databases of free physical blocks within the flash array andlogical-to-physical mappings for allocated blocks. In one embodiment,block accesses from external hosts may be intercepted in the followingmanner:

-   -   1) If a block read is requested by the external host and there        exists a logical-to-physical mapping for that block address, the        corresponding block of data is read from the flash array and        returned to the host.    -   2) If a block read is requested by the external host, but there        exists no logical-to-physical mapping for that block address,        the digital media storage device fabricates a block data read        response of all zeros (or other response) and returns the data        to the external host. The flash array is not accessed, nor is        any new storage or mapping allocated.    -   3) If a block write is requested by the external host and there        exists a logical-to-physical mapping for that block address, the        data provided by the host is written into the flash array at the        corresponding physical address.    -   4) If a block write is requested by the external host, but no        existing logical-to-physical mapping for that block address is        present, a currently unmapped physical block is taken from the        digital media storage device's internal persistent database of        free physical blocks and a new mapping is created from the block        address provided by the host to the physical address of the        allocated block. The data provided by the host is then written        to the flash array at that physical address. If no free physical        blocks are available, a block-level device access error is        returned to the host.

This dynamically-allocated logical-to-physical block address mappingscheme allows the present digital media storage device to reorganize thedata in its flash memory array without external, host-visibleside-effects. Furthermore, augmented by the firmware's understanding ofhigher-level FAT file system semantics, it allows the present storagedevice to manipulate the contents of files or folders stored in theflash array, without any explicit cooperation or synchronization fromthe external host device's software. Stated differently, the advantagesafforded by the present invention (e.g., the ability to manipulate thedata stored in the flash array) require no change to the physical host'sexisting firmware or application-level software. Hence, the drawbacks ofthe MMM2 scheme described above are avoided.

FIG. 1 illustrates an example of a digital media storage device in theformat of a media card 10 configured in accordance with an embodiment ofthe present invention. As illustrated, media card 10 includes aninterface 12 for communication with a host (e.g., a DSC or other digitaldevice). The physical and electrical make up of interface 12 will dependon the type of media card used (e.g., CF-I, CF-II, SD, etc.) but suchinterfaces are well known in the industry and need not be described indetail. Stated differently, such an interface is entirely conventionalin nature and conforms to the relevant industry specifications therefor,depending on the type of media card being used.

The host interface 12 is coupled to a bus 14 which is used forcommunicating electrical signals within the media card 10. In some casesbus 14 may be a dedicated bus between the interface 12 and a centralprocessing unit (CPU) 16, while in other cases it may be a more generalbus used for communications between the CPU and other components aswell. As with interface 12, the CPU 16 (which is communicatively coupledto bus 14) is a conventional feature of such media cards. In someembodiments a read/write memory (such as an SRAM) 18 may be used. Thisprovides a convenient storage location for CPU 16 when performingcomputations and the like. SRAM 18 may be communicatively coupled to bus14 (as shown) or may be communicatively coupled directly to CPU 16through a private interface (e.g., a separate memory bus).

A memory controller 20 and associated memory array 22 are also presentand the controller 20 is communicatively coupled to bus 14 and to thearray 22. In the illustration a flash memory array and flash memorycontroller are shown, however, other storage media and associatedcontrollers may be used. For example, a relatively new form of storagedevice incorporates a mini hard drive and associated controller within aphysical format compatible with conventional CF-II media cards. Suchstorage devices may be used in connection with the present invention,which is storage format-agnostic.

Also included in media card 10 is a wireless radio transceiver 24, whichmay be communicatively coupled to bus 14 so as to communicate with CPU16. The wireless radio 24 is an example of the peripherals discussedabove and in this embodiment preferably conforms to the IEEE 802.11a/b/g specifications, but in other embodiments other forms of wirelessradios or even other peripherals may be used. For example, wirelessradios conforming to the Bluetooth™ and/or GPS specifications may beused. Alternatively, or in addition, wireless radios conforming to theIEEE 802.16 standards may be used. The precise nature of the peripheralport is not critical to the present invention, though in several of theapplications described below a peripheral device that provides wirelesscommunications for media card 10 is required.

What is important is that the physical dimensions of the media card 10are compatible with existing media card interfaces of various hosts,such as DSCs and the like. In the past, media cards with wirelessnetwork functionality have been larger than their non-wireless capablecounterparts. DSCs (and other digital devices) usually (or often)enclose their media cards in the body of the host device. As a result,the larger, wireless-capable media cards were incompatible with manyexisting host devices. The present media card 10, however, is sized soas to fit within legacy host media card housings.

Other incompatibility problems which have prevented the use of mediacards with wireless functionalities with various hosts are even moredifficult to overcome. For example, prior media cards that haveincorporated flash memory with wireless network capabilities haverequired the host device to support them with appropriate softwaredrivers, making them incompatible with existing and legacy hosts. Thatis, existing hosts simply do not contain the firmware needed to operatewith previously available media cards having these functionalities. Incontrast, the present media cards are “self-hosted”, meaning that theyrequire no such firmware support from the host device. Instead, thepresent media cards themselves act as a host device with an onboardnetwork interface but present to the camera or other digital device withwhich the card is being used as a conventional block storage device.This means that the firmware used by existing and legacy host devicesneed not be altered in order to read and write images, audio files orother digital content, and metadata, to/from the present media cards.

In addition, a portion of the memory array 22 may be reserved forstoring the upload status information for images being transferred offof the media card. For example, in the case of a media card with awireless radio that is used in connection with uploading digital images,maintaining information regarding the status of any such uploads overthe wireless network may be important so that in cases where suchtransfers are interrupted, they can be resumed from a proper startingpoint once communications with the wireless network have beenreestablished. Further, maintaining such status information will alsoprovide the media card with the ability to determine when the originalimages can safely be removed from the media card memory array.

FIG. 2 illustrates a media card 26 configured in accordance with analternative embodiment of the present invention. In this media card 26,a flash memory controller 28 includes a host interface 30, for examplean SD or CF-I/CF-II interface. Controller 28 also includes a flash arrayinterface 32 which is communicably connected to the flash memory array34. In this example a NAND flash memory array is used, however, in otherembodiments a NOR flash memory array may be used.

The media card 26 also includes a wireless radio 36, which iscommunicably coupled to the flash controller 28 and the memory array 34.The wireless radio 36 may be a self-contained 802.11 a/b/g compliantcommunication device that includes both a media access controller, aRISC processor (with it attendant read/write memory and flash memory forstoring intermediate results and computer-readable instructions,respectively) and the wireless radio front end. The flash controller maybe such a controller as is available from Hyperstone AG of Konstanz,Germany, the memory array 34 may be a NAND flash array as is availablefrom Samsung, Inc. of Seoul, Korea, and the wireless radio may be such amodule as is available from Atheros Communications Inc. of Santa Clara,Calif. As indicated above, all of these modules are integrated within asingle SD or CF-I/CF-II card form compatible with existing host devices.

The wireless nature of the secondary interface (the interface with thehost device is considered the primary interface for the media card)allows digital content (e.g., images) to be transferred onto or off ofthe media card while still enclosed within the host's media card slot.Working from within the media slot allows the media card to draw powerfrom the host device, eliminating the need for an integral battery. Itis also possible to operate the media card and its wireless interfaceoutside of the host, provided power is supplied via the host interface(12, 30), or alternatively, in an embodiment that integrates a batteryonto the media card. As indicated above, to enable wireless transferfunctionality the present media card adds a wireless radio (e.g., anIEEE 802.11 a/b/g radio or Bluetooth radio, etc.), a media accesscontroller (MAC), and an embedded host CPU to the conventional flashcontroller functionality. Software components for interpreting thehost's file system and data stored in the memory array, connecting tolocal area and/or other networks (e.g., via TCP/IP protocols) andmanaging low-level driver tasks of the wireless interface hardware areall included for use by the embedded host CPU.

As discussed, media cards configured in accordance with presentinvention can be used in connection with a variety of devices, such asDSCs, digital video cameras, mobile phones, personal computers, personaldigital assistants, and similar devices. Much of the discussion belowwill focus on the use of such media cards with DSCs and further detailsof the firmware operation for the specific instance of a DSC writingimage data to a digital media storage device configured in accordancewith the present invention are presented below. However, it should beremembered that this is being done only so as to provide an example ofthe present invention. The overall scope of the invention is reflectedin the claims following this description and that scope should not beunnecessarily limited in view of the DSC examples presented herein.

Media cards that integrate a storage device with a wirelesscommunication system in accordance with the present invention may becompliant with any existing media card format (e.g., SD, MMC, CF, MS, orxD) so as to be compatible with a wide variety of DSCs and other hosts.In the case of a camera host, having an integrated wirelesscommunication device allows users to upload images (or other data) fromthe camera (i.e., the media card) to an alternative device (e.g., apersonal computer, a server or storage location associated with a localarea network, or an Internet-based computer/storage resource, etc.) atthe time the image is captured (if wireless communications areavailable) or at a later time, without having to tether the camera orthe media card to a physical interface (e.g., such as a universal serialbus (USB) cable or other interface). In the case where images areuploaded to an Internet-based computer/storage resource, those imagescan be managed through any conventional Web browser, either using apersonal computer, television and set-top box combination, mobile phone,or similar communication device.

Having thus described various media cards configured in accordance withthe present invention, we turn now to a discussion of variousapplications for such media cards as configured with one or morewireless network ports. In doing so, however, it should be recognizedthat these applications do not necessarily require the use of mediacards as described above. That is, in some cases the media cardfunctionality may be integrated within the host device itself instead ofbeing resident in a removable media card. While such solutions are notappropriate for legacy devices (at least not without substantial refitof those devices), they are appropriate for future host devices whichneed not be designed to include removable media cards. So, although thediscussion below assumes the use of a media card configured in themanner discussed herein, the present invention is also applicable tohost devices which include such features and functionality in theabsence of such a media card.

Additional embodiments of the present invention provide the ability to“tag” images with location information, time and/or date information, orother metadata, providing alternative means of image management. In somecases, the wireless communication devices integrated with the mediacards allows such cards to exchange cookies or other informationelements with similarly configured media cards that are in proximitywith one another (e.g., in an ad-hoc network fashion). This informationcan be used (in some cases in combination with social networkinformation) to facilitate sharing of images among users.

Using the present media cards may involve registering same with aservice provider, for example via a hosted Internet Web site or anothercomputer-based resource. Such registration may allow for configuring themedia card with network connection preferences and the like and may alsoestablish initial preferences for uploading of images to one or moredesignated storage locations. For example, a user may specify apreference to upload images to an existing electronic photo albummaintained by the user. As indicated above, several services alreadyexist for hosting such albums. Network parameters such as network namesor service set identifiers (SSIDs), encryption keys and the like mayalso be stored to the media card's private partition so as to facilitatecommunication with a preferred network (e.g., a user's home network). Inother cases, passwords associated with third party wireless networkaccounts held by the user may be so stored so as to facilitatecommunication between the media card and so-called wireless network “hotspots” (i.e., publicly accessible wireless network access pointsmaintained by third parties). Configuring the media card in this fashionmay require the user to interface the media card with a personalcomputer for the initial registration process.

Once the media card has been configured for use with one or morewireless networks it can be inserted in the host (here we assume a DSCfor convenience). As images are captured, save/delete decisions can bemade in-camera, in the conventional fashion. The media card will report(via the host camera's display) network availability (e.g., bydisplaying an appropriate predefined image stored in the media card viathe camera's image viewing screen). This allows a user to decide whetheror not to connect to an available network and upload images to thepreviously configured destination storage location. Upload status may bedisplayed on the camera display (e.g., again using one or morepredefined images). Thereafter the user can visit the storage location(e.g., by accessing his/her electronic photo album), and print orotherwise interact with his/her images.

By including the wireless network functionality in a media card, hostcompatibility is assured. That is, from the stand point of an existingDSC (or other device), the present media cards resemble conventionalstorage devices with a compatible interface. The wireless networkfunctionality need not be exposed to the host's processors or othercomponents. This allows the present media cards to be functional withthe existing installed base of non-wireless capable host devices whileat the same time expanding the functionality of those devices to permitwireless connectivity. Consumers remain free to purchase a camera (orother host device) of their choice and add wireless functionalitythrough selection of a media card. Consumers can also choose a photoportal (or other digital media storage facility) that meets their needs,rather than having such a portal be associated with their camera.

As more fully discussed below, a server layer isolates the present mediacard from the diverse photo portal interfaces. That is, rather thendirectly connecting to a third party photo portal or other storagelocations (as was described in the scenarios posited by Liepe), thepresent media cards will upload images through a known host (and herethe term “host” refers to a computer-based device and not the “hostdevice”, such as a DSC, into which the media card is placed), forexample a host on a LAN or accessible via a WAN and/or the Internet.This host will, in turn, store the images to the photo portal of theuser's choice (e.g., after performing any necessary image resizing ortranscoding or other digital content processing). The user can storehis/her preferences with the host (e.g., as preferences for a useraccount), among which may be the designation of a destination photoportal or other storage location.

The use of this intermediary host allows for providing additionalfunctionality. For example, automated enhancement features (such as redeye reduction for images) may be provided. In addition, the use of sucha host may allow for secure transfers across open wireless networks,such as are common at third party Internet cafes and the like. In someembodiments of the present invention, geotagging and/or timestampcorrection as well as image archiving capabilities (e.g., to alternativestorage media such as CDs or DVDs) may be provided through the host.Finally, the host acts as a platform for distributing firmware and “hotspot” (or other roaming) list updates to the media card.

Thus, among the capabilities delivered by media cards configured inaccordance with the present invention is the upload of images to thirdparty portals and image finishing service providers without need fortethering the host camera or media card to a personal computer. Currentdigital photography workflows typically require users to performmultiple steps to deliver images to portals (e.g., as may be found on aLAN or accessible via a WAN and/or the Internet). Typically, users mustfirst transfer the images from their cameras to their personalcomputers, and then run either Web-browser-based or custom clientsoftware provided by the portal service provider (e.g., Snapfish™Shutterfly™ or Ofoto™) to upload those images to the portal. Users canthen manage their electronic photo albums and order products based ontheir images, from simple prints to photo books, apparel or accessoriesimprinted with their photographs, archival media, etc.

The present invention removes the need for users to stage uploads ofimages via their personal computers by transferring images from themedia card to a managed server layer, and from there to one or morephoto service providers. Referring now to FIG. 3, when the userinitiates an upload from a media card 38 configured in accordance withthe present invention, the upload agent resident in the media cardcontacts the managed server 40, authenticates the user, and then uploadsthe images to the server using a specified transfer protocol. Theconnection to the server 40 may be made through a wireless networkaccess point 42 associated with the user's home (or other) network, orvia a public access point 44 as operated by a third party serviceprovider. Such an access point is generally part of a computer network(not shown) that provides access to the Internet or other network (e.g.,a LAN) through which server 40 can be reached. Such networks areconventional in nature and so are not shown in this diagram.

Once the images have been received at the server 40, software residentat the server accesses the user's account to determine where to storethose images. Such storage may be co-resident at the server 40 (or anassociated storage device or network) or may be associated with anonline service provider 46 the user has designated to receive theimages. Each of these service providers has its own specifications forimages to be uploaded, so if any resizing, transcoding or other imagemanipulation is needed server 40 can perform such tasks before uploadingthe images to the third party provider's Web site (again, such atransfer may be made via the Internet or other computer network, whichis not shown here so as to keep the present drawing simple in nature).Where so specified by a user, a variety of photo-finishing andphoto-sharing preferences may be implemented and the images transferredto more than one third party provider. For example, the server 40 mayupload the images to a on-line image storage location associated withone third party service provider and to the user's own Web site and/orWeb log (blog), hosted by a different service provider. In some cases,the third party service provider may be a social network provider suchas LinkedIn™ or Friendster™.

In order to facilitate the above-described processes, the presentinvention provides a binding of a media card to a user. On example ofsuch a binding makes use of a unique identifier for the media card, forexample a serial number or media access controller (MAC) address,preferably associated with the card at the time of its manufacture. Theassignment and use of such MAC addresses is well known in the computernetworking arts and so will not be described further herein. This uniqueidentifier can be used as an index to a particular user's account at theserver layer, requiring no user-identifying information to be stored onthe media card. Alternatively, user-identifying information may bestored on the media card for use in connection with operations for whichserver access is not required (e.g., interaction with a photo kiosk).

The presence of the server layer in the above-described process freesthe media card from the burden of connecting directly to adynamically-changing multitude of service providers and managing eachprovider's custom transfer protocols within the constrainedhardware/software environment of the media card. The server layer canoffer a variety of functionality, which is in most cases complementaryto those offered by the third party portal services. For example, server40 may be configured to perform any or all of the following actions:

-   -   1) Handle interrupted or duplicate transmissions gracefully.        That is, in the event any media card-to-server transmissions are        interrupted, then to avoid sending a potentially corrupt or        incomplete image file to the portal destination the server 40        may be configured to request retransmissions of such images upon        a successful reconnection to the media card. Similarly, the        media card may be configured to record information concerning        which images have already been successfully uploaded so as to        avoid sending duplicates thereof. Where such functionality is        not implemented, server 40 may be configured to compare newly        received images to previously received ones and eliminate        duplicates so that multiple copies of the images are not stored        to the third party sites. This can help reduce costs associated        with such storage and/or relieves the user from having to        perform such deletions at a later time. In either case,        duplicate images may be detected in a variety of ways, from        comparison of metadata associated with the images (e.g., time        stamps or file numbers) to actual image comparisons.    -   2) Provide feedback to the card and possibly the user as to        successful transfer completion. Server 40 may be configured to        wait until all images have been successfully uploaded thereto        before initiating any transmissions to the third party service        provider sites. In this way, users can be assured of not        deleting images from media card 38 before they have been        successfully transferred to off-camera storage. In other cases,        images may be deleted from the media card as soon as they have        been successfully transferred to server 40 (e.g., upon receiving        an indication from server 40 that the upload was successful).        Deletion may be performed automatically by the card or manually        by the user.    -   3) Resize and transcode images to meet portal requirements. As        indicated above, such actions may be necessary to comply with        requirements for uploading the images to the third party sites.    -   4) Act as an e-mail, MMS (cellular), and/or RSS (Web        syndication) gateway. Here, the server 40 provides services that        enhance the ability of the user to distribute his or her        electronic images. Server 40 may be configured to deliver the        images as e-mail attachments to pre-designated e-mail addresses        (e.g., such as the user's personal e-mail address or other        e-mail addresses) and/or to e-mail addresses specified by the        user after the images have been uploaded to server 40. In        addition to e-mail delivery, images may be communicated by MMS,        which is a service used by some mobile phones, RSS, which an        emerging syndication service based on the extensible markup        language (XML), or other means.    -   5) Secure transfers across an open wireless network. Many        wireless networks, especially those intended to be publicly        accessible, operate without any form of encryption. Users may        feel less secure about transferring their images across such        networks and so server 40 may be configured to establish a        secure session with media card 38 for the transfer of any        images. In such cases, media card 38 would need to be configured        with sufficient functionality to take part in such a        communication process. For example, media card 38 may need to be        configured with an appropriate digital certificate to        participate in secure socket layer (SSL) communications with        server 40. Image data would be encrypted at media card 38 prior        to transmission to server 40, where it would then be decrypted.        Thus, even if the wireless network itself operated without        encryption, the media card-to-server communications would remain        secure.    -   6) Provide automated image enhancement (e.g., red-eye        reduction). Where desired, some image enhancement or other        processing could be performed (typically under user direction)        on the images as they are stored at server 40 before they are        uploaded to other sites. Such services may be provided on a fee        basis or otherwise.    -   7) Provide geotagging and timestamp correction. As discussed        further below, geotagging and other services may be provided to        permit users to better manage their images. Such services can        also be used in conjunction with social network functionality to        permit users to share images that were captured in similar        locations and/or at similar times, etc.    -   8) Archive images to CD or DVD (or other media). Again, such        services may or may not be provided on a fee basis as an        alternative to archiving solutions offered by third parties.

Once the images have been successfully stored or uploaded to the user'schoice of providers, server 40 can so advise the media card 38 so thatstorage space on the card can be automatically freed up. Alternatively,receipt of the images at server 40 (vs. a final destination for theimages) may be sufficient for the server to advise media card 38 thatthe storage space can be made available for new images. That is, themedia card can be permitted to overwrite memory locations at which imagedata was previously stored once the images have been successfullytransferred off the camera. This allows the user to continue takingpictures without running out of storage space on media card 38. Theuploaded images may be managed using the tools provided by the onlinephoto-finishing and photo-sharing service providers, leaving theremainder of the user's photography workflow unchanged and undisrupted.

Most wireless networks, including the popular 802.11 a/b/g variants,require the user to provide configuration information to find andassociate with a network. Optionally, security tokens may be required toauthenticate and encrypt the connection. As discussed above, networksavailable for use with the present media cards include an individualuser's home wireless network, enterprise wireless networks, and free orfor-pay “wireless hot spot” networks available at many commerciallocations such as coffee shops, bookstores, airports and hotels.

An important feature of the present media card is that it requires nospecific software support from its host camera for managing andconfiguring the wireless interface. Thus, the card is compatible withall legacy cameras that support its card-type interface. Moreover, themedia card does not require any user input/output conduits of its own.This does not, however, mean that the media card requires no initialconfiguration. Instead, the required configuration information must bestored on the media card before it is inserted in the host camera. Thisconfiguration information is needed so that the media card can associatewith at least one known network.

The configuration information for this “initial” network may be storedin the media card's private partition or provided by coupling the mediacard with a personal computer (e.g., via a media card “reader” connectedto the personal computer through an interface such as a USB port) andrunning a configuration utility. This utility permits the user to storethe configuration information for one or more wireless networks on themedia card. In one embodiment the configuration information is stored tothe media card's memory array as a file using the file input/outputfacilities provided by the computer's operating system or the picturetransfer protocol (PTP) for cameras that support it. The camera hostingthe media card has no use for such a configuration file, as it does notrepresent image or other digital photography data, and so the file maybe stored in a separate directory from that where images are stored.Such a configuration file will, however, be compliant with the camera'sfile allocation table (FAT) file system. In some cases, configurationinformation for access to public wireless networks may be preloaded inthe media card, allowing for use thereof without any need for initialconfiguration of the card via a user's personal computer. Suchconfiguration via a personal computer (or other, similar means) wouldstill be required in order to make use of private (e.g., home, office,campus) networks.

This file system modification occasioned by the storage of the networkconfiguration information is detectable by the extended functionality ofthe media card and the newly stored data is interpreted by the mediacard firmware to extract the network information and configure thewireless interface accordingly. Such network configurations are wellknown in the wireless network arts and need not be repeated here. Whatis important for purposes of the present invention is that theconfiguration file is stored to a known memory location within thememory array of the media card. Computer-readable instructions stored onthe media card are executed by the CPU thereon and, as a result, the CPUis instructed to read this memory location and configure the wirelessradio in accordance therewith. Such configuration information mayinclude, for example, the MAC address of a wireless network accesspoint, the SSID therefor, the channel number for the network, anysecurity keys (if used by the network) and other information needed toassociate the media card with the access point. Once the media card isable to associate with at least one wireless network and is able toconnect to the server, all of the user's management tasks can beaccomplished through a Web interface and any new configurationinformation pushed to the media card by the server.

The presence of a wireless interface in the media card also permits thedigital photographer to upload pictures to photo-sharing sites whileaway from home (and, therefore, away from the user-configured “home”network). Typically, the networks needed for such “on the road” uploadsare “wireless hot spots”, which may or may not be free. Media cardsconfigured in accordance with the present invention maintain a “roaminglist” of such wireless hot spots and the configuration andauthentication information required for gaining access thereto. In thecase of free wireless hot spots, no authentication information may berequired, though web forms may have to be processed and completed toproceed. “Pay per use” billing at commercial hotspots can be supportedby informing the user of the cost of such sessions before they areinitiated and billing handled by an interaction between the server layerand the network provider.

Earlier, the concept of geotagging of images was mentioned. Digitalcameras typically associate non-visual information (so-called metadata)with images (usually at or about the time the image is recorded). Suchinformation can include the date and time the image was captured, thecamera settings used to take the image and user-customized comments. TheEXIF standard allows for the addition of arbitrary chunks of binary datato digital images and provides standardization for certain types ofdata, including geographical location information. Geographical data ofthis type is not typically inserted by digital cameras, but rather isinserted in “post-processing” of images by correlating the time stampsof images with a recorded GPS (global positioning system) trace made bythe photographer. The separate nature of the geographical data and theimage/time stamp data and the resulting need to marry the two in postprocessing makes geocoding of images a cumbersome and niche featureusing conventional workflows.

In contrast, the present media cards can automatically associategeographical location information of varying accuracy levels with imagescaptured by any digital camera. In one embodiment, the media card canhave access to GPS data with high accuracy. Such information may beprovided by a GPS receiver integral to the media card, or relayed via alocal wireless link (e.g. Bluetooth) from an external source of GPSdata.

Alternatively, the user's approximate location at the time an image wascaptured can be deduced by detecting wireless networks in the vicinityand correlating the list of networks so detected with a databasecontaining a mapping of networks to geographical locations. Wirelessnetworks, such as 802.11-compliant networks, are typically identified bya user-customized “network name” (the SSID) and a hardware-provided MACaddress (assigned uniquely at the time the access point ismanufactured). Hence, such networks can be uniquely identified.Recently, commercial and volunteer-assembled databases have beenestablished which provide mappings of these unique accees points MACs(and, in some cases SSIDs) to location coordinates (e.g., GPScoordinates). Since the present media cards are configured to operatewith wireless networks, the media cards are capable of detecting theSSID and MAC information broadcast by any nearby access points.

In one embodiment of the present invention this network identificationinformation is recorded on the media card at or about the time an imageis captured (or at other times as such wireless network identificationdata is received by the media card) and associated with images and/orwith timestamp information. That is, the network identificationinformation may be recorded at approximately the same time one or moreimages are captured and associated with those images in the same way asother metadata. Alternatively, or in addition, the media card may recordsuch network location information as it encounters various access pointbroadcasts, whether or not any images are actually captured at thosetimes. Such information can be recorded along with timestamps to act asa sort of digital record of the movement of the media card among variouswireless network areas.

In either case, once the images have been uploaded to the server layeror elsewhere, the network identification information may be used toindex appropriate databases to derive geographic location informationfor those networks. The geographic location information may then beassociated with the image data to geocode those images. In the casewhere the network location information was recorded at or about the sametime as the images, the approximate location of the images will beavailable. In the case where the network information was simply capturedas it was available, the actual location of the images may not beavailable, but its approximate location may be deduced from an analysisof the network information (and resulting geographic information)captured at times before and after the times the images were captured.In still further embodiments, both data sources (GPS data and networkidentification data) may combined in a form of assisted GPS to geocodethe images.

Once digital images have been geographically tagged, photo albummanagement tools and Web interfaces can take advantage of thisadditional information to present the user's photo collection in aspatial manner (in addition to the traditionally employed chronologicalmethods). Furthermore, the user can be offered enhanced photo searchcapabilities such as finding all photos taken near a location orlandmark without requiring the user to remember when s/he took aparticular picture.

The passive scanning of wireless networks to ultimately derivegeographical location may be termed “bread crumbing”. It is known thataccess points for all infrastructure (as opposed to ad-hoc)802.11-compliant wireless networks transmit a periodic beacon packet toadvertise their presence to mobile devices that may seek to access theirrespective networks. The access-point is typically both the managingentity of the network and the point at which the wireless network isbridged to a wired network. The beacon packets contain the unique MACaddress of the access point (a 48-bit binary string), as well as anoptional (but typically provided) human-readable network name (theSSID). Receiving the beacon packet does not require the receivingstation to have any additional information for accessing the network,such as authentication and encryption keys.

While it is probably not practical for a media card configured inaccordance with the present invention to keep its wireless transmitteron at all times, periodically turning on the wireless receiver to detectthe presence of 802.11 beacon packets in the vicinity represents only anincremental power drain on the battery of a host camera. Thus, mediacards may periodically power up their wireless receivers to recordwireless network beacons. The record represents a network-domainbreadcrumb trail of where the photographer has been (at least while thecamera was powered-on).

Once such a breadcrumb record of wireless networks is available, themedia card can employ any of several methods to convert the informationinto a trace of geographical locations:

-   -   1) In one case, requiring the least amount of additional storage        burden on the media card and power drain on the camera's        battery, the captured information (e.g., access point MAC        address and SSID) of the most recently encountered wireless        network is associate with any images taken by the user. This        data can be stored directly into EXIF-compliant headers of the        JPEG image file written by the camera or can be stored in a        second file named according to the naming convention of the        camera, but with a different filename extension than that of an        image file. When the user's pictures are uploaded via the        wireless interface, the server layer may convert the network        information stored with each image into a geographical location        by consulting a database. Using heuristics to match network        detection events and image capture times, the server may then        insert image location tags into the EXIF headers of the image        before transferring it to the user's preferred online provider.    -   2) In an alternative embodiment, if the media card has        sufficient on-board non-volatile storage space to contain a        mapping of global or regional network information to        geographical location, the conversion of network information to        location information can be done in an entirely camera-resident        manner. The “in media card” database can be kept up to date by        transferring any necessary updates during the user's connection        to the server layer for uploading images.    -   3) In yet a further embodiment, the camera can take advantage of        opportunistic connections to wireless networks to request from        the server layer the conversion of network information to        geographical information, without actually transferring any        images. In this mode, the media card may keep track of which        images have geographical information in the raw form of network        information and consult the server layer to look up the actual        geographical information. When the server layer provides that        information it can be associated with the image information in        the media card.

While many mappings of wireless network access point information togeographical location databases are presently being compiled, theopportunistic collection of such information may result in incompletecoverage of geographical information based on that one source alone. Toalleviate such coverage sparseness and augment the geographical locationdata, the present media cards may also use layer 3 (IP address)-baseddeduction of geographical location.

Layer 3 access to the network requires the media card to associate witha wireless network and receive a dynamically allocated IP address fromthe managing access point (typically through a communication protocollike DHCP (dynamic host configuration protocol)). While a camera ispowered on, if the media card finds a wireless network with which it canassociate, it can probe the network using IP packets of increasing TTL(time-to-live) thresholds to find the Internet-wide public IP address ofthe access point it is connected to. This IP address can then be used bythe server layer in a fashion similar to that discussed above to obtaina mapping of the IP address to geographical location of the accesspoint.

Note that the network based/network assisted geotagging of imagesdescribed herein is not limited to images captured on media cards havingwireless network interfaces. That is, similar operations may beperformed using DSCs having wireless network interfaces other than asincluded in a media card. As noted above, a small number of DSCs arestarting to incorporate such wireless network capabilities. The presentgeotagging techniques are equally applicable where such cameras are usedto capture images to conventional media cards.

Given the large, high resolution image files captured by DSCs and theoften limited upstream bandwidth provided by the (typically wired)network backhaul, e.g., past the point at which the local area and widearea networks are bridged, upon connection of the media card to awireless access point it may be desirable (for reasons of bandwidthlimitations determined after connection of the media card to thewireless access point or user preference) to transfer lower resolutionversions of all captured images quickly, before performing uploads ofthe high resolution counterparts. For example, thumbnail images (e.g.,having 160×120 pixel resolution) are typically embedded into the fullresolution image file header. In one embodiment of the present inventionthese thumbnails are extracted from the image files and transmitted,with no additional image processing required. Alternatively, or inaddition, screen resolution images (approximately 640-800 pixels on thelong side) can be generated by scaling the full resolution images usingcertain predefined scaling ratios (e.g., 1:1, 1:2, 1:4, 1:8 or 1:16), asdescribed below. The scaled images may then be uploaded in the fashiondescribed above for the thumbnails. These scalings are relatively lesscomputationally intensive than arbitrary scaling operations. In caseswhere a precise resolution is desired, a final up or down scalingoperation can be performed at the server layer once the scaled image hasbeen uploaded.

In still further embodiments of the present invention, media cardsconfigured with wireless radios may operate in a peer-to-peer fashion.In such a configuration, media cards may transmit a beacon, advertisingtheir presence to other similarly configured media cards. Individualcards may be uniquely identified through individual MAC addresses. Asmedia cards encounter one another they may associate with one another(e.g., via ad-hoc networks established between their respective wirelessradios) and record one another's MAC address, perhaps with associatedtimestamps. Such ad-hoc networks and their establishment are featureswell known in the art. However, the use of such networks to record theproximity of users of removable media cards is, to the knowledge of thepresent inventors, something not heretofore done. In other cases, themedia cards need not actually establish ad-hoc networks with one anotherand instead may simply record the observance of another media card'sbeacon. In some embodiments, beacon parameters (such as times oftransmission and whether or not such beacons are hidden or visible byother media cards) may be set by users as part of the configurationroutine for a media card.

Thereafter, once this information has been uploaded to the server layer(along with the image data, etc.), this “encounter” data may beassociated with user profile information that specifies a particularuser's contacts or other social network. If matches are uncovered,indicating that a user's media card encountered a media card of one ofthe user's contacts or other designated individuals, the user may be soinformed. This may act as a prompt for the user to share images with the“encountered user” or other wise communicate with that individual.

The “peer-to-peer” exchanges described above are not restricted to mediacards having wireless network capabilities. For example, wirelessnetwork-capable DSCs may engage in similar “encounters” with oneanother. As was the case for the media cards, the DSCs may record theobservance of one another's beacons (with or without establishing anactual ad-hoc network) and report such encounters to a server layer whencommunicatively coupled thereto (e.g., as part of a session during whichimages are uploaded to the server). The encounter information may beused to initiate a search for social network connections between theusers associated with the DSCs (or, more generally, the wirelesstransmitters that recorded the encounter as such wireless transmittersmay be associated with the DSC, the media card, or a peripheral deviceattached to or associated with the DSC).

Additional peer-to-peer exchanges may involve images themselves. Thatis, media cards and/or DSCs configured in accordance with the presentinvention may be configured to exchange images with one another over adhoc wireless networks. Appropriate user interfaces can be included withthe DSCs or media cards to permit user control of such exchanges. Forexample, users may be able to permit or deny such exchanges when mediacards/DSCs in proximity to one another establish the ad hoc network. Insome cases, these interfaces may include user-defined address booksconfigured to identify known associates of a user when beacons or otheridentifying criteria from a nearby media card/DSC is/are received.

Several operational modes for image uploads are available. In anopportunistic mode, the media card will associate with a wirelessnetwork and begin uploading images (or resume a previously interruptedupload) whenever it finds an available wireless network. In a userdriven mode, association with wireless networks will be limited topre-configured networks or undertaken only with user authorization.

Media card behavior in either basic operational mode may be furthercontrolled by a set of media handling policies, cognizant of therelevant attributes of the media card and its user, the server to whichit has connected (on the LAN or WAN), and the physical and/or networkenvironment in which the media card finds itself. These attributes mayinclude, but are not limited to, the following:

Place and time, relative to both physical position and network context

User identity or group affiliation

Device type or specific identity, potentially as authenticated to theserver

Server type or specific identity, potentially as authenticated to thedevice

Device and/or Server Copyright policy

Network bandwidth availability and/or cost of said bandwidth

Based on these attributes, policies in place may refine the basicoperational mode to determine whether and which media should be moved,and any additional processing required pre- or post-transfer. Decisionssuch as the desired quality and size of an image, whether authorship orcopyright metadata should be included, and whether images should bedeleted after transfer or merely copied to the server, all can be madeas a result of such policies.

Regardless of the operational mode and policies in place, a user may beapprised of the upload progress via information displayed on thecamera's image screen. That is, the present invention leverages theability of conventional DSCs to display images and/or play movies toapprise the user of the status of an upload of images or other data overa wireless network, even though the camera is not configured for suchtransfers.

In one embodiment of the present invention this functionality isachieved as follows. When the user wishes to upload one or more imageshe or she selects a file stored on the media card. Rather than a simpleimage file however, this file acts as a trigger for the media card toinitiate the upload. Such a file may be stored on the media card at thetime of its manufacture or as part of the initial configuration processdescribed above. Preferably, the file is associated with an image thatindicates the nature of the file so that when selected during playbackthe user is prompted to “play” the file in order to initiate the upload.That is, the file may be associated with an image that includes textinstructing the user to “Press Play to Initiate Image Upload” or similarinformation.

Upon selecting play (or a similar command), the file will cause theprocessor of the media card to execute computer-readable instructions totransmit the stored images over the wireless network. In addition, auser interface of sorts may be displayed to the user. The user interfacemay consist of a series of images or a movie that are designed toapprise the user of the status of the upload. As shown in FIG. 4A forexample, a first image 48 in the sequence may report the status of theconnection to the wireless network. Subsequent images 52 in thesequence, as shown in FIG. 4B, may also include a thumbnail 50 of thedigital image being transferred, and an updated status display showingprogress to date. The progress bars are not, however, real-time progressbars but rather stored images that are played out as the wireless radioreports of the progress of the image transfer. As the transferprogresses, images with more complete status bars may be played to theuser to give the illusion of a real-time progress update. The playbackof these images (or a movie) will stop (or a “completed” imagedisplayed) once the image transfer is complete. The wireless radio canthereafter be turned off.

Various embodiments of the present media cards may incorporate means forrestricting user-access to high resolution digital image files storedthereon. That is, some media cards configured in accordance withembodiments of the present invention may include a security layer thatbinds the stored images to a particular photofinishing provider. Thissecurity is based on a shared secret maintained on the media card aswell as at the provider. As a result, the media card must be physicallyprovided to an authorized photofinisher for processing, or unlockedwithin the context of a secure, authenticated network session, in orderto gain access to the high resolution images stored on the media card(e.g., for printing or other publishing). It is worth noting that accessto images stored on a media card configured in accordance with thepresent invention can be restricted in either or both of two ways: overthe wireless interface (by authenticating the server endpoint andrestricting the choice of image destination) or over the host interface(as discussed immediately above). Alternatively, or in addition, theonline destination may be restricted (e.g., on a per user basis) at theserver layer, as a lighter form of investment protection than on-cardimage locking.

The ability to restrict access to high resolution images stored on themedia card is made possible through an understanding of the file systemlayer, which governs the layout of files and directories (filegroupings) across the raw storage blocks of the media card. Thus,individual files may be classified into one (or more) of several contenttypes, and additionally, specific policy(ies) applied to files of eachcontent class. Policies can enforce file system permissions, e.g., bywithholding write or delete access. Policies can also specifytype-appropriate operations on the files themselves. The ability todynamically add or modify content and to observe user access to thecontent allows for establishing a limited user interface channel throughthe host device (e.g., a DSC). Status can be communicated to the uservia informative still or moving images as discussed above. User inputcan be detected based on file access patterns, including read, modify ordelete operations.

The present access control scheme allows an authorized host (e.g., acomputer system resident at or associated with a media card processingfacility) to operate at a higher privilege level (“unlocked”) than isaccorded to an un-authenticated host (“locked”). Media cards configuredin accordance with the present invention do not assume or require anyfunctionality outside conventional, industry standard-compliant mediacard functionality when operating with an un-authenticated host.Unlocking can occur in tandem with physically returning theun-authenticated host device to an authorized service location, oracross a network using appropriate (and conventional) authenticationtechniques. Policies may take into account whether the card is locked orunlocked at the time an operation is performed, allowing moreflexibility than traditional “all-or-nothing” access control schemes(e.g., a password protected drives or partitions).

In one embodiment, a media card configured in accordance with thepresent invention provides a still and/or moving image store for a DSC.The media card is locked while in the user's hands, and the policies setforth in Table 1 may be applied.

TABLE 1 Sample Policies for Media Card in Un-authenticated Host DeviceContent Class Locked? Policy Still Image, JPEG format Yes Transparentlyreplace image with screen resolution thumbnail Still Image, JPEG formatNo Restore original image Moving Image, AVI format Yes Quota byteswritten Moving Image, AVI format No Reset quota Other (unknown format)Yes Access error on read

To better appreciate the access controls provided in accordance withembodiments of the present invention, it is appropriate to review someunderlying characteristics of conventional removable media and hostdevices. Most DSCs available today employ non-volatile storage devicesinserted into their “digital film” slots. These non-volatile storagedevices use a “FAT” or file allocation table format to store imagescaptured by the DSC. The FAT file system has its origins in MS-DOS, andseveral variants are in use (e.g., FAT-16 and FAT-32). FAT is specifiedfor use in digital cameras as part of the JEITA CP-3461 standard, betterknown as DCF 2.0. In addition to the file system, DCF 2.0 (Sections 3.2and 5) specifies a directory hierarchy as well as directory and filenaming conventions that are a subset of FAT's 8+3 naming scheme.

Before storing images into a storage device (e.g., a flash memory of amedia card), the DSC will determine whether the device has beenformatted in accordance with the DCF specification. If not, the camerawill prepare the memory device to store data in an organized fashionthrough a process called “formatting.” Formatting logically erases allexisting data stored in the memory device and writes an empty filesystem structure in the FAT format. The camera's FAT software writes anempty File Allocation Table, which marks all data clusters to beavailable for storing new files into. An empty folder structure iswritten by initializing an empty Root Directory Structure. The camerawill then create new folders, in accordance with processes outlined inthe DCF specification, to provide logical separation of images storedinto the memory device (e.g., folders for different cameras that thememory device may be used in concurrently, for different dates that theuser takes pictures on, etc.).

JEITA CP-3451 “Exchangeable image file format for digital stillcameras”, better known as EXIF, is a companion to the DCF specification.EXIF specifies image, sound, and tag formats for storage within the filesystem structure mandated by DCF. For example, and as alluded to above,EXIF tags for “artist” (i.e., photographer) information and/or date/timeinformation can be used. The photographer information can be gatheredfrom user-provided account information. In addition, timezone referencescan be added in accordance with the present invention by using GPS datato determine the corresponding timezone and writing such informationand/or an absolute time into a UTC-referenced GPSDateStamp field. Inaddition, the information regarding peers (e.g., other users/DSCspresent at or near the location of a DSC having a media card configuredin accordance with the present invention) can be written to theMakerNote tag. As with location metadata, processing of such informationcan be performed in the media card, in the server layer or in acombination of these devices.

EXIF specifies the use of JPEG, known formally as ISO-IEC 10918-1/ITU-TRecommendation T.81, for compressed images, and Adobe TIFF 6.0 foruncompressed images. Images of either format are annotated withTIFF-style tags, recording camera and image parameters. The WAV formatis specified for audio annotations, which are to be associated withcaptured images.

In order to take advantage of the non-volatile storage medium, it isexpected that a camera will flush metadata as well as data block updatesto the flash at the end of each operation. Nonetheless, it is possiblefor a camera implementation to cache some or all of the FAT file systemmetadata, relying on a write-through cache discipline to keep the flashstorage in sync. As a result, updates to the metadata performed by themedia card may not be observed until the camera is next powered up, orwhenever the metadata cache is refreshed.

FAT file attributes can be used to mark a file read-only. DCF 2.0(Section 5.2.2.4) specifies support for the Read Only attribute toprevent accidental deletion (though some DSCs may not respect thisattribute). Some cameras allow toggling of the Read Only attribute(often represented as a key icon on the preview screen).

When an image is taken, a file is created within the file system by thecamera, after which the sequence of digital data encoding the image isstored in the file. The data is usually formatted in a conventionalcompressed image format (such as JPEG), as specified by DCF. In order tocomplete the action of creating the file and storing the image data, thecamera must go through the following set of actions (assuming there isfree space available on the device), although not necessarily in thisexact order:

-   -   1) Starting with the Root Directory Region of the file system,        traverse the file system blocks representing the directory        hierarchy stored on the device to find the Directory Table block        for the directory (folder) into which the new image is to be        stored.    -   2) Add an entry to that Directory Table block describing the new        file being created. This contains information about the name of        the file and where within the file system the beginning of the        data (i.e., the first data block) for that file resides.    -   3) Find a free data cluster based on the information stored in        the File Allocation Table. Mark that data cluster as being used        and store the a cluster's worth of image data in the continuous        range of blocks representing the cluster (FAT allows the cluster        size to be configured at the time the file system is created and        indicates this size between 2 KB and 32 KB in the File        Allocation Table structure).    -   4) Repeat step 3 as needed until all bytes of the image data are        written to the file system. As each new cluster of data is        written, singly-link it from the previous cluster such that the        image file can be read in a logically contiguous fashion even if        the data clusters are scattered around the media that the file        system is stored on.

All file system updates performed by the digital camera host appear aswrite accesses to the flash storage proxied by the media card storagedevice. The media card firmware can detect the completion of these setsof operations using a series of heuristics to be compatible with a widerange of implementations of the file system operations in digital stillcameras:

-   -   1) Wait for a pre-determined amount of time to expire after the        time of the last write access to the flash storage by the host        device. If more write accesses occur during the timeout period,        assume that the host device is continuing to update the file        system, reset the timer and keep waiting.    -   2) Once the timeout expiration occurs, scan the directory        structure of the file system and detect if any new files have        been created since the last scan by comparing the directory        structure against a copy that was saved during the last scan.    -   3) For each new file that was detected, walk the singly-linked        list of data clusters until the end of the list, at which point        the number of data bytes stored in the data clusters should        match the size of the file as indicated in the Directory Table        entry for the file. If the scan terminates early, assume that        the expiry timeout during step 1 was too short, invalidate the        scan results, increase the timeout and go back to step 1 to        allow the host device to complete updating the file system.

When the media card's firmware detects the completion of the creation ofnew image files on the file system, it starts a background task, runningat a lower priority to allow normal data access operations to remainunhindered, to create scaled down versions of the new images. For eachnew image created by the external host (most commonly the DSC):

-   -   1) Read the JPEG header of the file to get information on the        resolution (width and height in pixels) of the image. If the        JPEG image contains an optional EXIF header, inspect the header        for the presence of a camera orientation indication to detect        whether the picture was taken in landscape (larger dimension        along the top of the image) or portrait (smaller dimension along        the top of the image) orientation. If the EXIF information is        not available, assume a landscape image if the width of the        image is greater than the height or a portrait image otherwise.    -   2) Using the resolution and orientation information from the        image, pick one of the scaling ratios of 1:1, 1:2, 1:4, 1:8 or        1:16 to reduce the resolution of the image as close as possible,        but no smaller than, 320 pixels by 240 pixels for landscape        orientation images and 240 pixels by 320 pixels for portrait        orientation images while maintaining the aspect ratio of the        original image. These scaling ratios are unique in that the        computational overhead of JPEG decompression can be reduced to        make the operation take far less time compared to a complete        decompression followed by an arbitrary ratio scaling. In some        embodiments this scaling ratio can be a programmable feature        definable by a service provider offering the media device and        the ratio can be any ratio or ratios selected by the provider        (including 1:1, i.e., no reduced resolution). After the combined        JPEG decompression and fast-scaling-by-fixed-ratio operation,        further scale the image by simple decimation to have one        dimension equal 320 pixels or 240 pixels depending on the aspect        ratio of the original image.    -   3) Write a new compressed JPEG file containing the scaled image        into the flash memory by allocating data blocks from the        database of free physical blocks, without providing any new        logical-to-physical block address mappings for the file system.    -   4) In an atomic operation, scan the FAT file system structure        corresponding to the original image file to change the        physical-to-logical address translation of the data blocks        containing the FAT data clusters of the file. Specifically,        update the mappings of the first N blocks where N is the number        of blocks amounting to the size of the scaled image that was        written in step 3 to translate to the physical block addresses        holding the scaled image. Remove the mappings for the blocks        holding the remainder of the data clusters for the file (the        original file, being a much higher resolution image, contains        many more blocks than the scaled image).    -   5) Add a tracking entry to the persistent mapping database to        associate the now orphaned physical blocks holding the original        unmodified image file with the FAT filename (including the        complete folder path) of the scaled image (which, from the        camera perspective, now appears in place of the original        full-resolution image file). This association does not represent        a block-level mapping, but a mere hint to the firmware that if        the camera (or another external host) ever deletes the file        corresponding to the scaled image, the media card should free        the physical blocks corresponding to the full-resolution image,        effectively deleting it.

After the completion of these steps, each image captured by the DSC andstored onto the storage device has been replaced by an identical imageat a lower resolution (the original high resolution images still arestored on the media, but are inaccessible to the host). Thesereduced-resolution images are directly accessible by the DSC, allowingthe user to use the review and display features of the camera and makechoices about keeping or deleting images. The physical flash memoryblocks holding the data from the original full-resolution image have nological-to-physical address mappings within the media card, so thecamera or any other host accessing the media card cannot retrieve thehigh-quality full-resolution image for viewing, printing or transmissionby using block-level access semantics. Those data blocks are securedfrom any external access to the media card until a higher-levelauthentication exchange takes place between the device and anauthenticated/authorized host.

One of the challenges of performing image manipulation of the typedescribed above is that DSC manufacturers may choose to support only alimited subset of DCF directory structure and JPEG file syntax. Thecamera may also rely on vendor-specific EXIF header fields, for exampleto determine image orientation. Camera implementations often assume thatonly they will write to the media card; that is, the card is dedicatedto a single camera, and a PC host will only read/delete images. Thisimplies that the only images the camera is guaranteed to read properlyare ones the camera itself has formatted. The corollary is thatinconsistently formatted images may cause undesirable, and in generalunpredictable, behavior in camera. We refer to this vendor- orcamera-specific formatting as “Camera Normal Form”, and adhere to itwhen creating reduced resolution versions of images generated by thecamera. Note that these issues are also relevant for preloading still ormoving image content, and may require the user to capture an image withthe camera before the card can ascertain the appropriate CNF with whichto present any preloaded images.

If the user chooses to delete any of the images that were taken with thecamera previously, the camera needs to update the file systeminformation on the storage device. Specifically, the camera:

-   -   1) Writes to the Directory Table block for the folder containing        the image to be deleted, removing the name and file system        information for the file corresponding to the image from the        table.    -   2) Updates the File Allocation Table blocks to mark the data        cluster blocks used by the deleted file as free.

The file system update detection mechanism described earlier detectsthese operations as well, as all file system updates performed by thedigital camera host, including file deletions, appear as write accessesto the flash storage. Upon going through the directory structure scanfollowing the update detection, if the media card firmware notices thatsome files are now missing from the updated scan results, it infers thatthose files have been deleted from the file system. At this point, themedia card needs to take action because the files that were deleted bythe camera were not the original full-resolution copies of the image,but rather the scaled-down replacements. By using the information thatwas associated with the filenames of images that were replaced by thescaled-down copies, the firmware locates the physical data blocks in theflash memory that correspond to the high-resolution version of thedeleted files and returns those blocks to the pool of free physicalblocks in the persistent database.

In a further embodiment of the present invention, the consumer-side costof media card may be subsidized by a provider and/or consumers are“locked-in” to a particular provider's print fulfillment and otherservices “network”. Recall that the media card may act functionally as asecurity mechanism that restricts access to the print-worthy,full-resolution copies of users' photos. During normal operation, theuser can take pictures, review them on the viewing screen of the camera,delete unwanted pictures and even download limited screen-resolutioncopies of the pictures to a personal computer (e.g., either via a mediacard reader or by using the camera's own PC-connectivity solution). Inall of these user-driven operations where the media card is in “locked”(or un-authenticated) mode, the only memory blocks that can be accessedare the ones that hold the previously scaled-down versions of thepictures. Once the media card is returned to an authorized processinglocation for processing, that processing station (e.g., a personalcomputer running appropriate software) unlocks the media card anddelivers the full-resolution images to the provider's digital photoservices pipeline. Note that authentication for printing or otherprocessing can take place on a per-visit/per-media card basis (e.g., anauthentication may be valid for all stored images) or per-picture basis(e.g., authentication may apply only to specific pictures retrieved fromthe device) to facilitate various billing options.

The steps for setting up and operating the authentication mechanismbuilt into a media card configured in accordance with embodiments of thepresent invention are as follows (refer to FIG. 5):

-   -   1) Before a media card is provided to a user, an authentication        key (K_(A)) made up of random bits with sufficient cryptographic        entropy is selected. This key is stored in a region of the flash        memory that is never accessible to users (e.g., the same area        that holds the firmware). A copy of the key is retained in an        authentication database and associated with the serial number of        the corresponding media card (the serial number may also be        present in the device's firmware in an unrestricted readable        region).    -   2) During normal operation, the media card controller and        firmware remain in the “locked” mode, replacing the pictures        taken by users with screen-resolution thumbnails and securing        the full-resolution originals as described above.    -   3) When a media card is returned to an authorized processing        location, the processing software initiates the authentication        operation by contacting an authentication server (e.g., hosting        the authentication database) with a session initiation message        and receives an encryption salt (S_(SRVR)) dynamically derived        from a linear-feedback shift register (LFSR) counter and the        time of day. The server associates this salt with the        established connection and remembers it for the rest of the        exchange. The dynamic nature of this salt eliminates the        possibility of replay attacks if the unlocking station is        compromised or is running malicious software.    -   4) The processing station then presents the salt received from        the server to the media card being unlocked. The device responds        by providing a strong cryptographic hash (such as MD5) computed        over the secret authentication key (K_(A)), the serial number of        the device (N_(SERIAL)) and the server salt (S_(SRVR)). The        computed hash and serial number are transmitted to the server.    -   5) The server uses the serial number to look up its copy of the        media card's secret key in the authentication database. Using        that key, the serial number provided by the unlocking station        and the server salt associated with this connection (remembered        from step 3), the server computes the cryptographic hash using        the same algorithm employed by the media card in step 4. If the        hash computed by the server is identical to the one received        from the unlocking station, the authentication succeeds and the        legitimacy of the media card can be trusted. If the hash        comparison fails, the server indicates an authentication failure        and terminates the connection.    -   6) At this point the authentication server can trust that a        valid media card is present at the other end of the connection        (and not, for example, an arbitrary software automaton that may        be trying to gain access to the database and mine it for        information), but the authenticity of the server is not yet        proven to the media card. The device provides its own        dynamically-generated salt (S_(CARD)) which is transmitted to        the server by the unlocking station software. The server applies        the same cryptographic hash function that was employed in steps        4 and 5 to compute a signature using the secret key, the serial        number and the salt provided by the device. This signature is        offered back to the media card, which computes its own copy of        the hash using its knowledge of the K_(A), N_(SERIAL) and        S_(CARD). If the computed hash matches the one received from the        server, the authenticity of the server is proven because the        hash can only be computed correctly with knowledge of the        authentication key K_(A).    -   7) With the successful completion of step 6, the media card and        the server are assured of their mutual authenticity.        Furthermore, no trust is placed in the processing station which        is acting as an intermediary during the transaction because the        data transmitted therethrough is comprised of strong        cryptographic hashes that are dependent on a shared secret        (K_(A)) between the server and the device, but make it        impossible (or computationally very expensive) to derive the        secret knowing the resultant hashes and the other two        constituents of the hash operations due to the irreversibility.        At this point the server picks an encryption key (K_(E)), which        can be a dynamically-generated one-time key or another        pre-computed key that was stored in the database, encrypts it        using K_(A) and a cryptographic algorithm such as 3DES and        transmits it to the unlocking station. The unlocking station        provides this encrypted key to the media card, which decrypts it        using K_(A) and retrieves the unencrypted key K_(E) which is        used for the remainder of the bulk-data transfers off of the        card.    -   8) With the successful arrival of the bulk-data encryption key        the media card enters its “unlocked” state, whereby the FAT        file-system presented by the device makes available the full        length of the data stored in the files representing the        full-resolution photos taken by the user. However, when the        operating system running on the unlocking station reads the        blocks in the flash memory that correspond to the FAT data        blocks for the files, each block of data is returned to the host        via the physical interface (Compact Flash (CF), Secure Digital        (SD), etc.) after being encrypted by the bulk-data key K_(E).        The encrypted data is not usable by the processing station        because K_(E) is not known to it.    -   9) If the processing station is associated with an authorized        photo-finishing vendor (such as a retail outlet, a wholesale        printing service) whose identity can established to a sufficient        degree of certainty based on its network address and an identity        certificate (such as those employed by SSL), the authentication        server can share the bulk-data key K_(E) with the processing        station to allow it to decrypt the data retrieved from the media        card and make immediate use of the images.    -   10) If the processing station is not such a vendor (e.g., if it        is a user PC), then the unlocking is more restricted. In this        case the data retrieved from the media card is sent in its        encrypted form to the authentication server, where it is        decrypted and uploaded to the provider associated with the        serial number of the media card (e.g., as retrieved from the        authentication database).    -   11) Alternatively, the media card can offer both user PC and        authorized processing station hosts the ability to directly        receive and decrypt individual pictures. In this mode, the        processing station sends a request for a specific picture (based        on, for example, its filename) to the media card. The media card        dynamically generates an encryption key (K_(P)) for the picture        and associates it permanently with that picture by storing in a        non-host-accessible portion of the flash memory so that it may        be reused for subsequent decryptions. It then encrypts the        picture key with the authentication key K_(A) and returns the        encrypted results to the processing station. The processing        station then contacts the authentication server and makes the        request to decode the specific picture and passes along the        encrypted picture key. If the authentication server decides that        the processing station is authorized to decrypt this individual        picture and get access to its full-resolution copy, based either        on a pre-determined trust or authorization, or a just-in-time        authorization operation (such as credit card billing), it        decrypts the received picture key with K_(A) and returns it to        the processing station, which can then use the plain-text key to        decrypt the contents of that individual picture as it is read        off the media card.

Thus, content-aware digital media storage devices compatible withexisting specifications for media card formats for digital imaging andother devices have been described.

What is claimed is:
 1. A digital media storage device, comprising: a housing sized to be accommodated within a host; a host interface for receiving digital information from the host; included within the housing: a wireless communication interface; a controller coupled to the host interface and to the wireless communication interface; a first memory coupled to the controller for storing the digital information received from the host; and a second memory coupled to the controller, said second memory storing a wireless network configuration utility for the wireless communication interface, said configuration utility including controller-executable instructions for causing said controller to store configuration information for the wireless communication interface to associate with a wireless network, and (ii) controller-executable instructions to cause the controller to proxy accesses from the host interface to the first memory before resolving said accesses to specific blocks of data in the first memory.
 2. The digital media storage device of claim 1, wherein the second memory further stores controller-executable instructions for causing said controller to restrict access to high resolution digital image files stored in the first memory of the media card.
 3. The digital media storage device of claim 2, wherein the second memory further stores controller-executable instructions for causing said controller to permit access to the high resolution digital image files during an authenticated network session.
 4. The digital media storage device of claim 1, wherein the housing is sized to be compatible with one of a Secure Digital (SD) card interface, a Multi Media Card (MMC) interface, a Compact Flash (CF) card interface, a Memory Stick (MS) interface, or a Picture Card (xD) interface.
 5. The digital media storage device of claim 1, wherein the second memory further stores controller-executable instructions to cause the controller to mount the digital media storage device, obtain an inventory of files stored on the first memory, and make modifications to a file system within which said files are cataloged.
 6. The digital media storage device of claim 5, wherein said modifications include one or more of: removing files, renaming files, updating file attributes, and creating new files.
 7. The digital media storage device of claim 1, wherein the first memory is a flash memory.
 8. A digital media storage device, comprising a wireless transceiver, a controller and at least one memory, the wireless transceiver and the at least one memory being communicatively coupled to the controller, the wireless transceiver, the controller and the at least one memory included within a single housing sized to be compatible with one of a Secure Digital (SD) card interface, a Multi Media Card (MMC) interface, a Compact Flash (CF) card interface, a Memory Stick (MS) interface, or a Picture Card (xD) interface, wherein the at least one memory stores a wireless network configuration utility for the wireless transceiver, said configuration utility including controller-executable instructions for obtaining information concerning a wireless network, and controller-executable instructions for storing digital information received by the digital media storage device across a host interface, the controller being communicatively coupled to the host interface.
 9. The digital media storage device of claim 8, wherein the at least one memory comprises a flash memory.
 10. The digital media storage device of claim 8, wherein the at least one memory comprises two memories, one of which stores the wireless network configuration utility for the wireless transceiver, and the other of which is configured for storing the digital information received by the digital media storage device across the host interface.
 11. The digital media storage device of claim 10, wherein at least one of the two memories is a flash memory.
 12. The digital media storage device of claim 11, wherein the flash memory comprises a NOR flash memory.
 13. The digital media storage device of claim 11, wherein the flash memory comprises a NAND flash memory.
 14. The digital media storage device of claim 8, wherein the wireless network includes a wireless transceiver of a second digital media storage device having a wireless transceiver and at least one memory coupled to a controller, the second digital media storage device characterized by a housing sized to be compatible with one of a Secure Digital (SD) card interface, a Multi Media Card (MMC) interface, a Compact Flash (CF) card interface, a Memory Stick (MS) interface, or a Picture Card (xD) interface. 